WordPress

Thanks for the fix! The new version fixed it.

By the way, sorry to say, still a new issue came out with the very latest version just updated: I noticed it fixed the issue of the paragraphs breaking (doing a new line in a text block was not breaking the row in frontend) but now 2 new annoying issues happened:

1) The plugin is treating the output of shortcodes used in text blocks as if it is normal text in the text block. Not cool at all, as it converts new lines of the javascript in BR.
This for example, breaks the output of popupar plugins as the Revolution slider.

It wasn't happening till previous version.

Is like if a filter is added just before the code is printed, and breaks the output to new line even when is output from a shortcode.

2) BR tags added everywhere: I was writing a very simple slider plugin, all good, and was acting perfectly as shortcode in a text block of the King.
After the update (not even the latest, but the one before) I noticed spaces appearing after many tags like IMG and others.
Really, a BR tag appended to other html tags output of shortcodes.
Not very cool :)

After imprecating a while, I noticed that putting the shortcodes in a normal page without King, this wasn't happening.

The first issue seems to be solved if instead of text you put the shortcodes in a CODE block, but sometimes you don't want to do that.
The second issue, was impossible for me to solve, so for a new site I was building, I had to switch to my old composer.
Is a shame cos I was totally in love with the King... is just very very unstable at the moment...

You don't need to change the 'query_vars' callback name, but it wouldn't hurt. There's no reason a function cannot be named the same as a filter hook name, but I think it's slightly confusing to do so. Others probably think it is more clear, but I rarely see anyone doing it.

Please change the rewrite hook like this:

function custom_select_region() { add_rewrite_rule('^([^/]*)/([^/]*)/?','index.php?pagename=$matches[2]&region=$matches[1]','top'); add_rewrite_rule('^([^/]*)/([^/]*)/([0-9]{1,})/?','index.php?pagename=$matches[2]&region=$matches[1]&paged=$matches[3]','top');
}
add_action('init', 'custom_select_region', 0 );

I've come to the realization that I've been addressing little details without a good grasp of the overall situation. Time to take a step back and make sure I understand what you're trying to do as a test with the sample page.

I'm assuming you begin the test with requesting your-domain.tld/benelux/sample/

If so, checking for things in $_POST is pointless because we made a GET request. Thus get_posts() would just retu what it does by default, a page's worth of posts regardless of category. It seems to me you should be checking for $_GET['region'] on sample to get posts in the Benelux category, assuming the rewrite rules are working.

If that much works with using $_GET, then going to the next page is the next test. The link should be your-domain.tld/benelux/sample/2/, but I'm not confident that is what the next page link is pointing to. It might be missing the Benelux part.

Regardless of what the next page link is, entering your-domain.tld/benelux/sample/2/ in your browser will hopefully result in the next page of Benelux posts.

I do not see any reason to check for the 's' parameter on the sample page unless the same template is also used for the static front page of your site. (assuming the search form's action is still pointing to your site's home page)

If the front page is using the same template, you should get the region parameter from $_REQUEST['region'] so that either GET or POST requests are covered. There's a slight security issue with $_REQUEST, but it shouldn't be an issue in this context.

Now the search form itself. Does this appear on the sample page? If so, instead of trying to get the region out of the query, see if you can use $_GET['region'](or $_REQUEST['region'] on a front page template). Using the query for region should have worked, but it's more complicated. If $_GET['region'] works, it greatly simplifies things.

On whatever page loads after the form submits is where using $_POST is appropriate, like what you currently have for the sample page. However, if the page can be requested with GET, you need to use $_REQUEST['region']. $_POST['s'] is still OK because search requests will only come in via POST. Only the region parameter needs to work for both.

We will still need to get the query var part working at some point for other templates that use the main query and do not use get_posts(), but let's just focus on getting sample and the search form working first.

The behaviour you describe is currently by design. The criteria that makes the EU VAT number required takes precedence over the fact that the number may be hidden. If EU VAT number field will be: Required if user enters a company name (EU only) is enabled, and an EU customer enters a company name, then the VAT number becomes required. This applies to customers from your shop's country as well.

It might make sense to change the priority of the checks, so that when "Show EU VAT field when customer is located in base country" is not checked, then the VAT number becomes automatically "not required". I will take note of this for a future release.

In the meantime, you could configure the EU VAT Assistant as follows:
- EU VAT number field will be: Optional.
- Show EU VAT field when customer is located in base country: unchecked.

This will hide the VAT field for domestic customers, and allow other customers to enter their VAT number. If you are conceed that customers may forget to enter their VAT number, you could place it somewhere on the checkout page where it would be more prominent. You can find some information on how to do it in this thread: Move vat_number field in the edit address page.

Note
The option "Remove VAT customer is located in base country" is not related to the display or validation of VAT numbers. The meaning of that option is that the VAT gets deducted from the orders placed by customers from your shop's base country who enter a valid VAT number. That is, if you enable that option and a customer from the Netherlands enters a valid VAT number, then VAT won't be applied to the order. This option is normally left unchecked, as VAT is usually charged to all domestic customers.

Great! Now that I understand what you're trying to do, I *may* be able to help, as I'm doing something similar on one site, where I have a custom post type with a custom taxonomy, and for each taxonomy I want to list the post titles......I think you can modify this code to do what you want (I added some Idea to my code and I'll explain more below):

$terms = get_terms( 'retail_category', array('orderby' => 'name', 'order' => 'ASC') );

The first thing is to get all the terms in your custom taxonomy - in this part you would replace 'retail-category' with your custom taxonomy which is 'photo-gallery' - I'm sorting by name, which makes sense in your case too, but you can change the order by to whatever you like.

if ($terms) { foreach($terms as $term) { $args = array( 'post_type' => 'retail', 'posts_per_page' => -1, 'ignore_sticky_posts' => 1, 'orderby' => 'title', 'order' => 'ASC', 'tax_query' => array( array( 'taxonomy' => 'retail_category', 'field' => 'name', 'terms' => $term->name) ) );

In this section I am setting up my arguments for doing a new query (below) to find ALL (the -1) of the related custom posts fore EACH taxonomy term where the assigned taxonomy term matches (by name) the taxonomy in the FOREACH statement - my CPT is 'retail', yours is 'photos' (note: it's a better practice to name your CPTs with the singular term, not the plural, so your CPT really *should* be named 'photo' as each post is one photo, right? But honestly it's your call, you can keep it plural if you like :-) )

global $post; $myposts = new WP_Query($args); if ( $myposts->have_posts() ) { echo '<ul><li><h5 class="retailcatname">' . $term->name . '</h5><ul>';

Here is the query and if it finds posts within a term, then I'm echoing the name of the Taxonomy as a 'header' for the list of post titles that appear below it, you may not need to do this - and of course I'm using the UL and LI because mine is a real 'list'. If you don't want a header with the taxonomy term name, just leave out this echo and move right into the "while" part below.

while( $myposts->have_posts() ) : ($myposts->the_post()); echo '<li><a href="<?php the_permalink() ?>">'; echo the_title(); echo '</a></li>'; endwhile;

SO while I have matching posts for the taxonomy term, I list each and display it's title as a link (A). You can display whatever you want, the thumbnail and/or the content. NOTE THAT the "global $post" in the above section is required to access the post data.

echo '</ul></li></ul>'; } }
}

Closing the list....not necessary if you're not using a list.

I think if you modify this to use your custom taxonomy (photo-gallery) and custom post type (photos) and then in the section with the "while" statement just echo what you want displayed, this might work for you.

Good luck!

I lost a lot of time for this problem, there were two alteatives to resolve it:

1. Using the shortcodes [polylang]:

// [polylang lang="en"]English[/polylang][polylang lang="sp"]Spanish[/polylang]
function polylang_shortcode($atts, $content = null)
{ if (empty($content)) retu ''; extract( shortcode_atts( array('lang' => ''), $atts ) ); if (empty($lang)) retu "<h3>You must specify 'lang' using shortcode: polylang</h3>"; retu ($lang == pll_current_language()) ? $content : '';
}
add_shortcode('polylang', 'polylang_shortcode');

Refer: https://wordpress.org/support/topic/polylang-shortcode-like-qtranslate-for-theme-options-and-text?replies=19

This trick saved me many times, I think that the developers should integrate it.

Unfortunately in many fields of this theme I can't use shortcodes, so I could not use this trick.

2. Using php code, and I resolved in this way, so I had to edit the php file of theme section:

<?php $url = 'http://' . $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI']; // get current url if (false !== strpos($url,'/en/')) { // if in url I find the string /en/ echo 'eng'; } elseif (false !== strpos($url,'/it/')) { // if in url I find the string /it/ echo 'ita'; } ?>

Thank you. More payment gateways would be great and that + mobile compatibility would IMHO make your plugin one of the best membership solutions for WordPress out there right now.

I've tried the checkout on an iPhone 6+, a Samsung Galaxy S7 and an iPad Air 2 (in portrait mode to simulate a cell phone view) and it's all the same.

This is a screenshot of my phone when you click the PayPal button:

http://i.imgur.com/7oS6ouS.png

You can resize your browser to see how illegible it is at that size.

Note how different the PayPal checkout screen looks when you click the PayPal checkout button on this page, which uses the WP Shopping Cart plugin:

http://wpsesame.com/diy-wordpress-website/

THAT is the link to the truly responsive PayPal checkout, and doesn't require PayPal on mobile checkout.

https://wordpress.org/plugins/wordpress-simple-paypal-shopping-cart/

Maybe you can compare the code of that plugin to yours and see what they do differently that makes theirs responsive and not yours? Might that help?

Otherwise, I really hate to say it, but I'm going to have to uninstall yours and use a membership solution, because over half of my traffic is coming from mobile right now and this is without a doubt costing me a LOT of money. I really like Simple Membership, and I've purchased add-ons, so I don't want to have to do that.

Thanks in advance for your help.